6장. 자료 찾아 붙이고, 알아서 처리하기

출처: 『AI 엔지니어링』(Chip Huyen 지음, 한국어판) | 원서 6장 대응

코드는 분위기만 — Python·검색·함수 같은 말은 몰라도 됩니다. 표의 '비유'와 '위험'만 봐도 충분해요.

0장에서 RAG는 "자료를 펴 주고 답하게 하는 오픈북" 이라고 했다.

에이전트는 "도구를 쥐고 알아서 여러 단계를 처리하는 비서" 라고 했다.

이 장은 그 두 가지를 한 칸 더 깊이 들어간다.

오픈북 시험에서 어떤 자료를 어떻게 찾아 붙일지, 비서가 어떤 도구를 어떤 순서로 쓸지 를 본다.

0. 이 장의 새 단어

0장에 없는 말은 딱 3개만 새로 꺼낸다.

이 3개와 0장 용어만 알면 6장은 끝난다.

각 단어는 [한 문장 뜻 + 일상비유 + 한 줄 예] 3종으로 적었다.

청크(chunk)

한 문장 뜻 — 긴 문서를 검색하기 좋게 잘라 놓은 한 조각.

일상비유 — 책을 통째로 복사하지 않고, 필요한 페이지만 찢어 둔 것. 한 장씩 잘라 두면 원하는 페이지만 쏙 뽑기 쉽다.

한 줄 예 —

# 긴 문서를 짧은 조각들로 잘라 둠
chunks = split(long_document)  # 예: ["1쪽 내용", "2쪽 내용", ...]

검색기(retriever)

한 문장 뜻 — 질문과 관련된 청크를 골라 가져오는 부분. RAG의 절반을 맡는다.

일상비유 — 도서관 사서. "환불 규정 어디 있어요?" 물으면 관련 책장으로 데려가 딱 맞는 페이지를 뽑아 준다.

한 줄 예 —

# 질문과 가까운 조각들을 찾아 옴
docs = retriever.search("환불 규정")  # → 관련 청크 몇 개

도구(tool)

한 문장 뜻 — 에이전트가 직접 불러 쓰는 외부 기능 하나. 검색·계산기·이메일 발송 같은 것.

일상비유 — 비서 책상 위의 연장통. 전화기, 계산기, 달력이 놓여 있고, 일에 맞는 걸 골라 집어 든다.

한 줄 예 —

# 에이전트가 골라 쓸 수 있는 연장 목록
tools = [calculator, web_search, send_email]

이런 적 있죠?

회사 환불 규정을 챗봇에 물었더니, 그럴듯하지만 우리 회사엔 없는 규정을 지어냈다.

모델은 우리 회사 문서를 본 적이 없다. 머리에 없는 걸 물으니 지어낸 것이다.

그래서 답하기 전에 "이 문서 먼저 보고 답해" 라고 자료를 펴 줬다.

그런데 사내 문서가 5천 쪽이다. 통째로 펴 주면 모델이 5천 쪽을 다 못 읽는다.

읽어도 엉뚱한 페이지에 집중하고, 게다가 매번 5천 쪽 값을 돈으로 낸다.

그래서 5천 쪽을 한 쪽씩 청크로 잘라 두고, 질문이 오면 검색기가 딱 맞는 몇 쪽만 뽑아 펴 준다.

이게 RAG를 제대로 굴리는 방법이다.

여기서 한 발 더 나가면, 검색 자체를 비서가 알아서 고르는 단계가 생긴다.

# 통째로 펴 주기 (망함)
ask(prompt + 사내문서_5천쪽)   # 너무 길어 못 읽고, 비용 폭발

# 잘라 두고 골라 펴 주기 (RAG)
chunks = split(사내문서_5천쪽)        # 청크로 자르고
docs = retriever.search(질문)         # 검색기가 관련 몇 쪽만 뽑고
ask(prompt + docs)                    # 그것만 보고 답함

이 장은 이 두 줄짜리 이야기를 천천히 푼다.

자료를 어떻게 잘 잘라 잘 찾아 붙일지, 그리고 비서가 도구를 어떤 순서로 쓸지.

이 장에서 딱 4가지만

① 검색기 — 자른 청크 중 질문에 맞는 걸 골라 오는 부분. 단어로 찾기 vs 뜻으로 찾기, 두 길이 있다. ② 청킹 — 긴 문서를 어떻게 자르느냐가 검색 품질을 좌우한다. 너무 크게도, 너무 잘게도 안 된다. ③ 도구 — 에이전트가 쥐는 연장. 자료를 늘리는 것, 능력을 늘리는 것, 세상을 바꾸는 것 세 종류다. ④ 여러 단계 처리 — 에이전트는 생각 → 행동 → 관찰을 반복하고, 가끔 자기 답을 되돌아본다(성찰).

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• 단어로 찾는 검색과 뜻으로 찾는 검색을 구분한다.
• 청크를 자르는 방식이 검색에 주는 영향을 설명한다.
• 에이전트가 쓰는 도구를 세 종류로 구분한다.
• 에이전트가 여러 단계를 처리하는 흐름을 설명한다.

개념 1 — 검색기 (두 가지 찾는 법)

망가지는 장면

사용자가 "트랜스포머 아키텍처 설명해줘" 라고 물었다.

검색기가 가져온 건 AI 모델 문서가 아니라, 전기 변압기와 영화 트랜스포머 문서였다.

"트랜스포머" 라는 글자 만 보고 찾았더니, 뜻 이 엉뚱한 문서가 끌려온 것이다.

일상비유

도서관에서 책을 찾는 두 가지 방법.

하나는 제목에 그 단어가 들어간 책만 뽑기. 빠르지만 "강아지" 책을 "개" 로 찾으면 못 찾는다.

다른 하나는 사서에게 "내용이 비슷한 책" 을 부탁하기. "강아지" 라 물어도 "개" 책을 같이 꺼내 준다. 대신 사서를 부르는 데 시간과 돈이 더 든다.

한 문장 정의 — 검색기는 자른 청크 중 질문에 맞는 걸 골라 오는 부분이며, 단어 형태로 찾는 법 과 뜻(임베딩)으로 찾는 법 두 가지가 있다.

단어로 찾기는 0장 용어가 필요 없다. 그냥 글자를 맞춰 본다.

뜻으로 찾기는 0장의 임베딩(뜻을 숫자 좌표로 바꾼 것)을 쓴다. 좌표가 가까우면 뜻이 비슷한 것이다.

가장 단순한 규칙 — 정확한 단어(오류 코드, 제품명)를 찾을 땐 단어 기반, 비슷한 뜻을 찾을 땐 뜻 기반. 운영에선 둘을 섞는다.

예시 폭격

예시 1 (완성예 — 따라 읽기).

질문: "환불 어떻게 받나요?"

단어 기반은 "환불" 글자가 든 청크만 가져온다. "취소하고 돈 돌려받기" 청크는 "환불" 글자가 없어 놓친다.

뜻 기반은 "취소하고 돈 돌려받기" 도 뜻이 가까워 같이 가져온다.

# 단어 기반: 글자 "환불" 이 있어야만 잡힘
word_search("환불")      # → "환불 정책" 청크만

# 뜻 기반: 뜻이 가까우면 잡힘
meaning_search("환불")   # → "환불 정책" + "취소 후 환급" 청크

예시 2 (부분완성 — 빈칸 채우기).

이번엔 반대 경우다.

질문이 오류 코드 "EADDRNOTAVAIL(99)" 처럼 정확한 글자 가 중요하다면?

# 정확한 코드를 찾을 땐 ____ 기반이 유리
______search("EADDRNOTAVAIL(99)")   # 빈칸: word

빈칸 정답은 word(단어 기반)다.

뜻으로 바꾸면 이상한 코드가 숫자 좌표로 뭉개져 희석되기 때문이다.

예시 3 (독립 적용 — 혼자 풀기).

"우리 회사 사훈과 비슷한 분위기의 문장" 을 찾고 싶다.

정답: 뜻 기반.

"비슷한 분위기" 는 글자가 아니라 뜻이라서, 단어 기반으로는 잡히지 않는다.

미니 시나리오

이럴 때 이렇게 — 사용자가 "그 에러 코드 자료 줘" 하면 단어 기반부터.

"비슷한 사례 더 보여줘" 하면 뜻 기반.

둘 다 필요하면 단어 기반으로 후보를 빨리 추리고, 뜻 기반으로 그중 좋은 걸 다시 고른다.

개념 2 — 청킹 (어떻게 자르느냐)

망가지는 장면

"I left my wife a note(아내에게 쪽지를 남겼다)" 라는 문장을 자료로 넣었다.

자르는 자리를 잘못 잡아 "I left my wife(아내를 떠났다)" 와 "a note(쪽지)" 로 쪼개졌다.

앞 조각만 검색되면 뜻이 완전히 뒤집힌다. 자르는 자리가 의미를 죽인 것이다.

일상비유

긴 글을 가위로 자르기.

문장 한가운데를 싹둑 자르면 양쪽 다 말이 안 된다.

문단 끝, 문장 끝처럼 말이 끊겨도 되는 자리 에서 잘라야 한다.

한 문장 정의 — 청킹은 긴 문서를 청크로 자르는 일이며, 자르는 크기와 겹침 이 검색 품질을 크게 좌우한다.

가장 단순한 규칙 — 조각끼리 살짝 겹치게 자른다. 그래야 자르는 자리에 걸친 정보가 적어도 한 조각엔 온전히 들어간다.

예시 폭격

예시 1 (완성예 — before/after).

before: 겹침 없이 자름.

split("아내에게 쪽지를 남겼다", 크기=6, 겹침=0)
# → ["아내에게 쪽지를", "남겼다"]   ← 둘 다 반쪽짜리

after: 살짝 겹쳐 자름.

split("아내에게 쪽지를 남겼다", 크기=6, 겹침=2)
# → ["아내에게 쪽지를", "쪽지를 남겼다"]  ← 뒷조각이 온전함

예시 2 (부분완성 — 빈칸 채우기).

청크를 너무 크게 자르면 한 조각에 잡다한 내용이 다 들어가 검색이 둔해진다.

너무 잘게 자르면 조각 수가 폭발해 비용이 오른다.

# 절반으로 잘게 자르면 조각 수는 ____ 가 된다
split(글, 크기=512)   # 크기=1024 였을 때보다 조각 수가 ____
# 빈칸: 두 배

작은 청크는 더 촘촘하지만, 그만큼 저장할 조각도 두 배로 늘어난다.

예시 3 (독립 적용 — 혼자 풀기).

질의응답(Q&A) 문서를 자른다면 어디서 잘라야 할까?

정답: 질문-답 쌍이 한 조각에 같이 들어가게.

질문과 답이 다른 조각으로 갈라지면, 답 조각만 검색됐을 때 무슨 질문의 답인지 알 수 없다.

미니 시나리오

이럴 때 이렇게 — 어떤 크기가 좋을지 모르면 한 값에 못 박지 말고 여러 크기로 실험해 본다.

최적 크기는 자료마다 다르다. 정답은 실험이 알려 준다.

개념 3 — 도구 (세 종류 연장)

망가지는 장면

"내일 비 오면 우산 챙기라고 알려줘" 라고 했더니, 모델이 날씨를 모른 채 둘러대는 답을 내놨다.

모델은 인터넷을 직접 볼 수도, 알림을 보낼 수도 없었다.

손에 쥔 연장(도구)이 하나도 없으니 여러 단계 일을 못 해낸 것이다.

일상비유

비서 책상 위 연장통.

연장은 크게 세 칸으로 나뉜다.

자료를 더 찾아 오는 칸(검색), 모델이 약한 일을 대신하는 칸(계산기), 세상을 실제로 바꾸는 칸(이메일 발송).

한 문장 정의 — 도구는 에이전트가 골라 쓰는 외부 기능이며, 자료를 늘리는 것·능력을 늘리는 것·세상을 바꾸는 것 세 종류로 나뉜다.

가장 단순한 규칙 — 세상을 바꾸는 도구(이메일·돈·삭제)는 위험이 크다. 그런 도구는 실행 전에 사람 확인을 한 번 거치게 한다.

신뢰 못 할 인턴에게 운영 데이터베이스 삭제 권한을 주지 않는 것과 같다.

예시 폭격

예시 1 (완성예 — 도구 고르기).

"123 곱하기 456 알려줘" 라는 질문.

모델은 큰 곱셈을 자주 틀린다. 그래서 계산기 도구(능력 확장)를 집어 든다.

# 모델 머리로 계산 X → 계산기 도구에 맡김
calculator(123 * 456)   # → 56088 (정확)

예시 2 (부분완성 — 빈칸 채우기).

"이 메일 김 대리한테 보내줘" 라는 질문.

이건 세상을 실제로 바꾸는 일이다. 어느 칸 도구일까?

# 받은편지함을 실제로 건드림 → ____ 행동 도구
______(받는이="김대리", 내용=메일)   # 빈칸: 쓰기

빈칸 정답은 쓰기(쓰기 행동)다.

이런 도구는 한 번 실행되면 되돌리기 어려워, 보내기 전에 사람 확인을 권한다.

예시 3 (독립 적용 — 혼자 풀기).

"최신 환율 찾아서 알려줘" 는 어느 칸 도구일까?

정답: 자료 찾는 칸(지식 증강).

모델 머릿속 지식은 과거에 멈춰 있어, 최신 환율은 검색 도구로 새로 가져와야 한다.

미니 시나리오

이럴 때 이렇게 — 도구를 무작정 많이 쥐여 주지 않는다.

연장이 많을수록 비서가 헷갈려 엉뚱한 걸 집는다.

자주 안 쓰는 도구는 빼고, 자주 같이 쓰는 두 도구는 하나로 합친다.

개념 4 — 여러 단계 처리 (생각·행동·관찰, 그리고 되돌아보기)

망가지는 장면

비서에게 "30개 객실에 50명 배정해줘" 라고 했다.

비서가 40명만 배정해 놓고 "다 했습니다!" 라고 했다.

자기가 한 일을 한 번도 되돌아보지 않아서, 빠뜨린 10명을 못 본 것이다.

일상비유

요리하는 사람의 머릿속.

"소금을 넣자(생각) → 넣는다(행동) → 맛을 본다(관찰)" 를 반복한다.

그리고 가끔 "어, 이거 짜네? 다시 하자" 하고 되돌아본다. 이 되돌아보기가 성찰이다.

한 문장 정의 — 에이전트는 생각 → 행동 → 관찰 을 반복하며 일을 처리하고(ReAct), 가끔 자기 답을 되돌아봐 실수를 고친다(성찰).

가장 단순한 규칙 — 단계가 많을수록 실수가 쌓인다. 한 단계 정확도가 90%라도 열 번 거치면 전체는 크게 떨어진다. 그러니 단계는 적게, 위험한 단계 뒤엔 되돌아보기를 둔다.

예시 폭격

예시 1 (완성예 — 한 바퀴 따라가기).

"내일 비 오면 우산 챙기라고 알려줘" 를 비서가 처리하는 한 바퀴.

# 생각: 날씨를 먼저 알아야 한다
# 행동: 날씨 검색 도구 사용
weather = web_search("내일 날씨")    # → "비"
# 관찰: 비가 온다
# 생각: 그럼 알림을 보내야 한다
send_alert("우산 챙기세요")

생각하고, 도구를 쓰고, 결과를 보고, 다음을 정한다. 이게 한 바퀴다.

예시 2 (부분완성 — 빈칸 채우기).

단계가 쌓이면 실수도 쌓인다.

한 단계 정확도가 90%(0.9)일 때, 두 단계면 전체 정확도는?

# 두 단계 모두 맞을 확률
0.9 * 0.9   # = ____   (빈칸: 0.81)

0.81, 즉 81%다.

단계가 늘수록 이 값은 계속 작아진다. 그래서 단계를 줄이는 게 중요하다.

예시 3 (독립 적용 — 혼자 풀기).

"50명을 30개 객실에 배정" 작업에서 성찰을 어디에 두면 좋을까?

정답: 배정을 끝냈다고 판단한 직후.

"정말 50명을 다 배정했나?" 를 되돌아보면, 40명만 한 실수를 잡아낼 수 있다.

미니 시나리오

이럴 때 이렇게 — 비서가 "다 했어요" 라고 할 때마다 곧이곧대로 믿지 않는다.

"요청한 걸 빠짐없이 했나?" 를 한 번 되돌아보게 시키면, 빠뜨린 일을 스스로 찾아낸다.

단, 매 단계마다 되돌아보면 느려지니, 위험하거나 마무리하는 단계에만 둔다.

정리

핵심은 세 줄이다.

자료는 청크로 잘라 두고, 검색기가 질문에 맞는 조각만 골라 펴 준다(RAG).

도구는 세 종류 — 자료 찾기·능력 메우기·세상 바꾸기. 세상 바꾸는 도구는 사람 확인을 거친다.

에이전트는 생각→행동→관찰을 반복하고, 위험한 단계 뒤엔 되돌아본다. 단계가 적을수록 실수가 적다.

한 걸음 더 ▸ (지금 몰라도 됨)

"언제 단어 기반이고 언제 뜻 기반인가", "청크를 얼마로 자르나" 같은 균형 판단은 더 깊은 주제다. 지금은 "정확한 단어는 단어 기반, 비슷한 뜻은 뜻 기반, 운영은 둘 섞기" 라는 규칙 하나만 들고 가면 된다. 자세한 저울질은 천천히 익히면 된다.

다음 장 예고 — 다음 장에서는 모델 자체를 우리 일에 맞게 더 가르치는 법(파인튜닝)을 본다. (지금 몰라도 됩니다.)